Building management system with involvement user interface

ABSTRACT

A method in a Building Management System (BMS) includes presenting a user interface to a user on a user device that allows the user to efficiently view logical relationships between objects in the BMS. The method includes presenting, on the user interface, a first object and a second object. The second object is affected by the first object. The first object is presented on a first side of the second object on the user interface. The method also includes receiving, via the user interface, an input from the user including a selection of the second object, and presenting, on the user interface, a third object used to control equipment of the BMS in response to the input from the user. The third object is affected by the second object and presented on a second side of the second object opposite the first side.

BACKGROUND

The present disclosure relates generally to a building management system(BMS) and more specifically to user interfaces associated with the BMS.A BMS is, in general, a system of devices configured to control,monitor, and manage equipment in or around a building or building area.A BMS can include, for example, an HVAC system, a security system, alighting system, a fire alerting system, any other system that iscapable of managing building functions or devices, or any combinationthereof. These systems can require significant amounts of time andeffort to configure properly. In addition, users may struggle tounderstand all of the information contained in such systems.

SUMMARY

One implementation of the present disclosure is a method in a buildingmanagement system (BMS). The method includes presenting a user interfaceto a user on a user device; presenting, on the user interface, a firstobject used to control equipment of the BMS; presenting, on the userinterface, a second object used to control equipment of the BMS, thesecond object affected by the first object, the first object presentedon a first side of the second object on the user interface; receiving,via the user interface, an input from the user, the input including aselection of the second object; and presenting, on the user interface, athird object used to operate equipment of the BMS responsive to theinput from the user, the third object affected by the second object andpresented on a second side of the second object, the second sideopposite the first side.

In some embodiments, the method further includes presenting, on the userinterface, a fourth object used to control equipment of the BMS, thefirst object affected by the fourth object, the fourth object presentedon a second side of the first object opposite the first side of thesecond object.

In some embodiments, the input from the user is a first input, and themethod further includes receiving, via the user interface, a secondinput from the user, the second input including a selection of thefourth object; and presenting, on the user interface, a fifth objectused to control equipment of the BMS, the fourth object affected by thefifth object, the fifth object presented on a second side of the fourthobject opposite the second side of the first object.

In some embodiments, the method further includes removing, from the userinterface, the fourth object responsive to the input from the user.

In some embodiments, the method further includes presenting, on the userinterface, a connector between the first object and the second object,wherein the connector identifies a logical relationship between thefirst object and the second object.

In some embodiments, the connector is interactive and allows the user toview a priority associated with the logical relationship between thefirst object and the second object.

In some embodiments, a value or state associated with the first objectis equal to a value or state associated with the second object, and themethod further includes presenting, on the user interface, a visualindication that accentuates the connector.

In some embodiments, the third object is an unbound object that is nolonger valid within the BMS, and the method further includes presenting,on the user interface, a visual indication that alerts the user of theunbound object.

In some embodiments, the method further includes presenting, on the userinterface, an object address associated with the first object, theobject address selectable by the user to navigate to a settings pageassociated with the first object.

Another implementation of the present disclosure is a BMS including oneor more processors and one or more computer-readable storage mediahaving instructions stored thereon that, when executed by the one ormore processors, cause the one or more processors to implementoperations. The operations include presenting a user interface to a useron a user device; presenting, on the user interface, a first object usedto control equipment of the BMS; presenting, on the user interface, asecond object used to control equipment of the BMS, the first objectaffected by the second object, the first object presented on a firstside of the second object on the user interface; receiving, via the userinterface, an input from the user, the input including a selection ofthe second object; and presenting, on the user interface, a third objectused to control equipment of the BMS responsive to the input from theuser, the second object affected by the third object, the third objectpresented on a second side of the second object, the second sideopposite the first side.

In some embodiments, the operations further include presenting, on theuser interface, a fourth object used to control equipment of the BMS,the first object affected by the fourth object, the fourth objectpresented on a second side of the first object opposite the first sideof the second object.

In some embodiments, the input from the user is a first input, and theoperations further include receiving, via the user interface, a secondinput from the user, the second input including a selection of thefourth object; and presenting, on the user interface, a fifth objectused to control equipment of the BMS, the fifth object affected by thefourth object, the fifth object presented on a second side of the fourthobject opposite the second side of the first object.

In some embodiments, the operations further include removing, from theuser interface, the fourth object responsive to the input from the user.

In some embodiments, the operations further include presenting, on theuser interface, a connector between the first object and the secondobject, wherein the connector identifies a logical relationship betweenthe first object and the second object.

In some embodiments, the third object is an unbound object that is nolonger valid within the BMS, and the operations further includepresenting, on the user interface, a visual indication that alerts theuser of the unbound object.

Yet another implementation of the present disclosure is a device in aBMS. The device includes one or more processing circuits configured toimplement operations, including presenting a user interface to a user ona user device; presenting, on the user interface, a first object used tocontrol equipment of the BMS; presenting, on the user interface, asecond object used to control equipment of the BMS, the second objectaffected by the first object, the first object presented on a first sideof the second object on the user interface; receiving, via the userinterface, an input from the user, the input including a selection ofthe second object; and presenting, on the user interface, a third objectused to control equipment of the BMS responsive to the input from theuser, the third object affected by the second object and presented on asecond side of the second object, the second side opposite the firstside.

In some embodiments, the operations further include presenting, on theuser interface, a fourth object used to control equipment of the BMS,the first object affected by the fourth object, the fourth objectpresented on a second side of the first object opposite the first sideof the second object.

In some embodiments, the input from the user is a first input, and theoperations further include receiving, via the user interface, a secondinput from the user, the second input including a selection of thefourth object; and presenting, on the user interface, a fifth objectused to control equipment of the BMS, the fourth object affected by thefifth object, the fifth object presented on a second side of the fourthobject opposite the second side of the first object.

In some embodiments, the operations further include presenting, on theuser interface, a connector between the first object and the secondobject, wherein the connector identifies a logical relationship betweenthe first object and the second object.

In some embodiments, the third object is an unbound object that is nolonger valid within the BMS, and the operations further includepresenting, on the user interface, a visual indication that alerts theuser of the unbound object.

Those skilled in the art will appreciate this summary is illustrativeonly and is not intended to be in any way limiting. Other aspects,inventive features, and advantages of the devices and/or processesdescribed herein, as defined solely by the claims, will become apparentin the detailed description set forth herein and taken in conjunctionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drawing of a building equipped with a HVAC system, accordingto some embodiments.

FIG. 2 is a schematic of a waterside system which can be used as part ofthe HVAC system of FIG. 1, according to some embodiments.

FIG. 3 is a block diagram of an airside system which can be used as partof the HVAC system of FIG. 1, according to some embodiments.

FIG. 4 is a block diagram of a BMS which can be used in the building ofFIG. 1, according to some embodiments.

FIG. 5 is a block diagram of a server associated with the BMS of FIG. 4,according to some embodiments.

FIG. 6 is a drawing of an example involvement user interface associatedwith the BMS of FIG. 4, according to some embodiments.

FIG. 7 is a drawing of another example involvement user interfaceassociated with the BMS of FIG. 4 that provides an example of how theinvolvement user interface responds to a user input, according to someembodiments.

FIG. 8 is a drawing of another example involvement user interfaceassociated with the BMS of FIG. 4 that provides an example of priority,according to some embodiments.

FIG. 9 is a drawing of another example involvement user interfaceassociated with the BMS of FIG. 4 that provides an example of an unboundobject, according to some embodiments.

FIG. 10 is a flow diagram of an example process for presenting logicalrelationships between objects associated with the BMS of FIG. 4 to auser via a user interface, according to some embodiments.

DETAILED DESCRIPTION Overview

Referring generally to the FIGURES, a BMS with an involvement userinterface is shown, according to various embodiments. The involvementuser interface functionality allows users of the BMS to easily identifyand troubleshoot various problems by illustrating logical relationshipsbetween various objects on a single, intuitive user interface.

The involvement user interface may improve current troubleshootingprocesses, which typically require users to have significant knowledgeof the BMS and may require users to spend long periods of timenavigating through a user interface to identify logical relationshipsbetween objects. For example, in some previous systems, the easiest wayfor users to identify logical relationships between objects may be todelete an object and observe effects of the deletion. The involvementuser interface may significantly decrease troubleshooting time byproviding users with an interactive visual representation of logicalrelationships between objects. Additionally, the involvement userinterface may allow a variety of different personnel (e.g., operators,administrators) to achieve a better understanding of the BMSconfiguration, thereby providing improved efficiency in operating andmaintaining the BMS.

Building Management System

Referring now to FIG. 1, a perspective view of a building 10 is shown.Building 10 is served by a BMS (sometimes referred to as a buildingautomation system (BAS)). The BMS that serves building 10 includes anHVAC system 100. HVAC system 100 may include a plurality of HVAC devices(e.g., heaters, chillers, air handling units, pumps, fans, thermalenergy storage, etc.) configured to provide heating, cooling,ventilation, or other services for building 10. For example, HVAC system100 is shown to include a waterside system 120 and an airside system130. Waterside system 120 may provide a heated or chilled fluid to anair handling unit of airside system 130. Airside system 130 may use theheated or chilled fluid to heat or cool an airflow provided to building10. In some embodiments, waterside system 120 is replaced with a centralenergy plant such as central plant 200, described with reference to FIG.2.

Still referring to FIG. 1, HVAC system 100 is shown to include a chiller102, a boiler 104, and a rooftop air handling unit (AHU) 106. Watersidesystem 120 may use boiler 104 and chiller 102 to heat or cool a workingfluid (e.g., water, glycol, etc.) and may circulate the working fluid toAHU 106. In various embodiments, the HVAC devices of waterside system120 may be located in or around building 10 (as shown in FIG. 1) or atan offsite location such as a central plant (e.g., a chiller plant, asteam plant, a heat plant, etc.). The working fluid may be heated inboiler 104 or cooled in chiller 102, depending on whether heating orcooling is required in building 10. Boiler 104 may add heat to thecirculated fluid, for example, by burning a combustible material (e.g.,natural gas) or using an electric heating element. Chiller 102 may placethe circulated fluid in a heat exchange relationship with another fluid(e.g., a refrigerant) in a heat exchanger (e.g., an evaporator) toabsorb heat from the circulated fluid. The working fluid from chiller102 and/or boiler 104 may be transported to AHU 106 via piping 108.

AHU 106 may place the working fluid in a heat exchange relationship withan airflow passing through AHU 106 (e.g., via one or more stages ofcooling coils and/or heating coils). The airflow may be, for example,outside air, return air from within building 10, or a combination ofboth. AHU 106 may transfer heat between the airflow and the workingfluid to provide heating or cooling for the airflow. For example, AHU106 may include one or more fans or blowers configured to pass theairflow over or through a heat exchanger containing the working fluid.The working fluid may then return to chiller 102 or boiler 104 viapiping 110.

Airside system 130 may deliver the airflow supplied by AHU 106 (i.e.,the supply airflow) to building 10 via air supply ducts 112 and mayprovide return air from building 10 to AHU 106 via air return ducts 114.In some embodiments, airside system 130 includes multiple variable airvolume (VAV) units 116. For example, airside system 130 is shown toinclude a separate VAV unit 116 on each floor or zone of building 10.VAV units 116 may include dampers or other flow control elements thatcan be operated to control an amount of the supply airflow provided toindividual zones of building 10. In other embodiments, airside system130 delivers the supply airflow into one or more zones of building 10(e.g., via air supply ducts 112) without using intermediate VAV units116 or other flow control elements. AHU 106 may include various sensors(e.g., temperature sensors, pressure sensors, etc.) configured tomeasure attributes of the supply airflow. AHU 106 may receive input fromsensors located within AHU 106 and/or within the building zone and mayadjust the flow rate, temperature, or other attributes of the supplyairflow through AHU 106 to achieve setpoint conditions for the buildingzone.

Referring now to FIG. 2, a block diagram of a central plant 200 isshown, according to an exemplary embodiment. In brief overview, centralplant 200 may include various types of equipment configured to serve thethermal energy loads of a building or campus (i.e., a system ofbuildings). For example, central plant 200 may include heaters,chillers, heat recovery chillers, cooling towers, or other types ofequipment configured to serve the heating and/or cooling loads of abuilding or campus. Central plant 200 may consume resources from autility (e.g., electricity, water, natural gas, etc.) to heat or cool aworking fluid that is circulated to one or more buildings or stored forlater use (e.g., in thermal energy storage tanks) to provide heating orcooling for the buildings. In various embodiments, central plant 200 maysupplement or replace waterside system 120 in building 10 or may beimplemented separate from building 10 (e.g., at an offsite location).

Central plant 200 is shown to include a plurality of subplants 202-212including a heater subplant 202, a heat recovery chiller subplant 204, achiller subplant 206, a cooling tower subplant 208, a hot thermal energystorage (TES) subplant 210, and a cold thermal energy storage (TES)subplant 212. Subplants 202-212 consume resources from utilities toserve the thermal energy loads (e.g., hot water, cold water, heating,cooling, etc.) of a building or campus. For example, heater subplant 202may be configured to heat water in a hot water loop 214 that circulatesthe hot water between heater subplant 202 and building 10. Chillersubplant 206 may be configured to chill water in a cold water loop 216that circulates the cold water between chiller subplant 206 building 10.Heat recovery chiller subplant 204 may be configured to transfer heatfrom cold water loop 216 to hot water loop 214 to provide additionalheating for the hot water and additional cooling for the cold water.Condenser water loop 218 may absorb heat from the cold water in chillersubplant 206 and reject the absorbed heat in cooling tower subplant 208or transfer the absorbed heat to hot water loop 214. Hot TES subplant210 and cold TES subplant 212 may store hot and cold thermal energy,respectively, for subsequent use.

Hot water loop 214 and cold water loop 216 may deliver the heated and/orchilled water to air handlers located on the rooftop of building 10(e.g., AHU 106) or to individual floors or zones of building 10 (e.g.,VAV units 116). The air handlers push air past heat exchangers (e.g.,heating coils or cooling coils) through which the water flows to provideheating or cooling for the air. The heated or cooled air may bedelivered to individual zones of building 10 to serve the thermal energyloads of building 10. The water then returns to subplants 202-212 toreceive further heating or cooling.

Although subplants 202-212 are shown and described as heating andcooling water for circulation to a building, it is understood that anyother type of working fluid (e.g., glycol, CO₂, etc.) may be used inplace of or in addition to water to serve the thermal energy loads. Inother embodiments, subplants 202-212 may provide heating and/or coolingdirectly to the building or campus without requiring an intermediateheat transfer fluid. These and other variations to central plant 200 arewithin the teachings of the present invention.

Each of subplants 202-212 may include a variety of equipment configuredto facilitate the functions of the subplant. For example, heatersubplant 202 is shown to include a plurality of heating elements 220(e.g., boilers, electric heaters, etc.) configured to add heat to thehot water in hot water loop 214. Heater subplant 202 is also shown toinclude several pumps 222 and 224 configured to circulate the hot waterin hot water loop 214 and to control the flow rate of the hot waterthrough individual heating elements 220. Chiller subplant 206 is shownto include a plurality of chillers 232 configured to remove heat fromthe cold water in cold water loop 216. Chiller subplant 206 is alsoshown to include several pumps 234 and 236 configured to circulate thecold water in cold water loop 216 and to control the flow rate of thecold water through individual chillers 232.

Heat recovery chiller subplant 204 is shown to include a plurality ofheat recovery heat exchangers 226 (e.g., refrigeration circuits)configured to transfer heat from cold water loop 216 to hot water loop214. Heat recovery chiller subplant 204 is also shown to include severalpumps 228 and 230 configured to circulate the hot water and/or coldwater through heat recovery heat exchangers 226 and to control the flowrate of the water through individual heat recovery heat exchangers 226.Cooling tower subplant 208 is shown to include a plurality of coolingtowers 238 configured to remove heat from the condenser water incondenser water loop 218. Cooling tower subplant 208 is also shown toinclude several pumps 240 configured to circulate the condenser water incondenser water loop 218 and to control the flow rate of the condenserwater through individual cooling towers 238.

Hot TES subplant 210 is shown to include a hot TES tank 242 configuredto store the hot water for later use. Hot TES subplant 210 may alsoinclude one or more pumps or valves configured to control the flow rateof the hot water into or out of hot TES tank 242. Cold TES subplant 212is shown to include cold TES tanks 244 configured to store the coldwater for later use. Cold TES subplant 212 may also include one or morepumps or valves configured to control the flow rate of the cold waterinto or out of cold TES tanks 244.

In some embodiments, one or more of the pumps in central plant 200(e.g., pumps 222, 224, 228, 230, 234, 236, and/or 240) or pipelines incentral plant 200 include an isolation valve associated therewith.Isolation valves may be integrated with the pumps or positioned upstreamor downstream of the pumps to control the fluid flows in central plant200. In various embodiments, central plant 200 may include more, fewer,or different types of devices and/or subplants based on the particularconfiguration of central plant 200 and the types of loads served bycentral plant 200.

Referring now to FIG. 3, a block diagram of an airside system 300 isshown, according to an example embodiment. In various embodiments,airside system 300 can supplement or replace airside system 130 in HVACsystem 100 or can be implemented separate from HVAC system 100. Whenimplemented in HVAC system 100, airside system 300 can include a subsetof the HVAC devices in HVAC system 100 (e.g., AHU 106, VAV units 116,duct 112, duct 114, fans, dampers, etc.) and can be located in or aroundbuilding 10. Airside system 300 can operate to heat or cool an airflowprovided to building 10 using a heated or chilled fluid provided bywaterside system 200.

In FIG. 3, airside system 300 is shown to include an economizer-type airhandling unit (AHU) 302. Economizer-type AHUs vary the amount of outsideair and return air used by the air handling unit for heating or cooling.For example, AHU 302 can receive return air 304 from building zone 306via return air duct 308 and can deliver supply air 310 to building zone306 via supply air duct 312. In some embodiments, AHU 302 is a rooftopunit located on the roof of building 10 (e.g., AHU 106 as shown inFIG. 1) or otherwise positioned to receive both return air 304 andoutside air 314. AHU 302 can be configured to operate exhaust air damper316, mixing damper 318, and outside air damper 320 to control an amountof outside air 314 and return air 304 that combine to form supply air310. Any return air 304 that does not pass through mixing damper 318 canbe exhausted from AHU 302 through exhaust damper 316 as exhaust air 322.

Each of dampers 316-320 can be operated by an actuator. For example,exhaust air damper 316 can be operated by actuator 324, mixing damper318 can be operated by actuator 326, and outside air damper 320 can beoperated by actuator 328. Actuators 324-328 can communicate with an AHUcontroller 330 via a communications link 332. Actuators 324-328 canreceive control signals from AHU controller 330 and can provide feedbacksignals to AHU controller 330. Feedback signals can include, forexample, an indication of a current actuator or damper position, anamount of torque or force exerted by the actuator, diagnosticinformation (e.g., results of diagnostic tests performed by actuators324-328), status information, commissioning information, configurationsettings, calibration data, and/or other types of information or datathat can be collected, stored, or used by actuators 324-328. AHUcontroller 330 can be an economizer controller configured to use one ormore control algorithms (e.g., state-based algorithms, extremum seekingcontrol (ESC) algorithms, proportional-integral (PI) control algorithms,proportional-integral-derivative (PID) control algorithms, modelpredictive control (MPC) algorithms, feedback control algorithms, etc.)to control actuators 324-328.

Still referring to FIG. 3, AHU 302 is shown to include a cooling coil334, a heating coil 336, and a fan 338 positioned within supply air duct312. Fan 338 can be configured to force supply air 310 through coolingcoil 334 and/or heating coil 336 and provide supply air 310 to buildingzone 306. AHU controller 330 can communicate with fan 338 viacommunications link 340 to control a flow rate of supply air 310. Insome embodiments, AHU controller 330 controls an amount of heating orcooling applied to supply air 310 by modulating a speed of fan 338.

Cooling coil 334 can receive a chilled fluid from waterside system 200(e.g., from cold water loop 216) via piping 342 and can return thechilled fluid to waterside system 200 via piping 344. Valve 346 can bepositioned along piping 342 or piping 344 to control a flow rate of thechilled fluid through cooling coil 334. In some embodiments, coolingcoil 334 includes multiple stages of cooling coils that can beindependently activated and deactivated (e.g., by AHU controller 330, byBMS controller 366, etc.) to modulate an amount of cooling applied tosupply air 310.

Heating coil 336 can receive a heated fluid from waterside system 200(e.g., from hot water loop 214) via piping 348 and can return the heatedfluid to waterside system 200 via piping 350. Valve 352 can bepositioned along piping 348 or piping 350 to control a flow rate of theheated fluid through heating coil 336. In some embodiments, heating coil336 includes multiple stages of heating coils that can be independentlyactivated and deactivated (e.g., by AHU controller 330, by BMScontroller 366, etc.) to modulate an amount of heating applied to supplyair 310.

Each of valves 346 and 352 can be controlled by an actuator. Forexample, valve 346 can be controlled by actuator 354 and valve 352 canbe controlled by actuator 356. Actuators 354-356 can communicate withAHU controller 330 via communications links 358-360.

Actuators 354-356 can receive control signals from AHU controller 330and can provide feedback signals to controller 330. In some embodiments,AHU controller 330 receives a measurement of the supply air temperaturefrom a temperature sensor 362 positioned in supply air duct 312 (e.g.,downstream of cooling coil 334 and/or heating coil 336). AHU controller330 can also receive a measurement of the temperature of building zone306 from a temperature sensor 364 located in building zone 306.

In some embodiments, AHU controller 330 operates valves 346 and 352 viaactuators 354-356 to modulate an amount of heating or cooling providedto supply air 310 (e.g., to achieve a setpoint temperature for supplyair 310 or to maintain the temperature of supply air 310 within asetpoint temperature range). The positions of valves 346 and 352 affectthe amount of heating or cooling provided to supply air 310 by coolingcoil 334 or heating coil 336 and may correlate with the amount of energyconsumed to achieve a desired supply air temperature. AHU controller 330can control the temperature of supply air 310 and/or building zone 306by activating or deactivating coils 334-336, adjusting a speed of fan338, or a combination of both.

Still referring to FIG. 3, airside system 300 is shown to include abuilding management system (BMS) controller 366 and a client device 368.BMS controller 366 can include one or more computer systems (e.g.,servers, supervisory controllers, subsystem controllers, etc.) thatserve as system level controllers, application or data servers, headnodes, or master controllers for airside system 300, waterside system200, HVAC system 100, and/or other controllable systems that servebuilding 10. BMS controller 366 can communicate with multiple downstreambuilding systems or subsystems (e.g., HVAC system 100, a securitysystem, a lighting system, waterside system 200, etc.) via acommunications link 370 according to like or disparate protocols (e.g.,LON, BACnet, etc.). In various embodiments, AHU controller 330 and BMScontroller 366 can be separate (as shown in FIG. 3) or integrated. In anintegrated implementation, AHU controller 330 can be a software moduleconfigured for execution by a processor of BMS controller 366.

In some embodiments, AHU controller 330 receives information from BMScontroller 366 (e.g., commands, setpoints, operating boundaries, etc.)and provides information to BMS controller 366 (e.g., temperaturemeasurements, valve or actuator positions, operating statuses,diagnostics, etc.). For example, AHU controller 330 can provide BMScontroller 366 with temperature measurements from temperature sensors362 and 364, equipment on/off states, equipment operating capacities,and/or any other information that can be used by BMS controller 366 tomonitor or control a variable state or condition within building zone306.

Client device 368 can include one or more human-machine interfaces orclient interfaces (e.g., graphical user interfaces, reportinginterfaces, text-based computer interfaces, client-facing web services,web servers that provide pages to web clients, etc.) for controlling,viewing, or otherwise interacting with HVAC system 100, its subsystems,and/or devices. Client device 368 can be a computer workstation, aclient terminal, a remote or local interface, or any other type of userinterface device. Client device 368 can be a stationary terminal or amobile device. For example, client device 368 can be a desktop computer,a computer server with a user interface, a laptop computer, a tablet, asmartphone, a PDA, or any other type of mobile or non-mobile device.Client device 368 can communicate with BMS controller 366 and/or AHUcontroller 330 via communications link 372.

Referring now to FIG. 4, a block diagram of a BMS 400 is shown,according to an example embodiment. BMS 400 can be implemented inbuilding 10 to automatically monitor and control various buildingfunctions. BMS 400 is shown to include BMS controller 366 and aplurality of building subsystems 428. Building subsystems 428 are shownto include a building electrical subsystem 434, an informationcommunication technology (ICT) subsystem 436, a security subsystem 438,a HVAC subsystem 440, a lighting subsystem 442, a lift/escalatorssubsystem 432, and a fire safety subsystem 430. In various embodiments,building subsystems 428 can include fewer, additional, or alternativesubsystems. For example, building subsystems 428 can also oralternatively include a refrigeration subsystem, an advertising orsignage subsystem, a cooking subsystem, a vending subsystem, a printeror copy service subsystem, or any other type of building subsystem thatuses controllable equipment and/or sensors to monitor or controlbuilding 10. In some embodiments, building subsystems 428 includewaterside system 200 and/or airside system 300, as described withreference to FIGS. 2 and 3.

Each of building subsystems 428 can include any number of devices,controllers, and connections for completing its individual functions andcontrol activities. HVAC subsystem 440 can include many of the samecomponents as HVAC system 100, as described with reference to FIGS. 1-3.For example, HVAC subsystem 440 can include a chiller, a boiler, anynumber of air handling units, economizers, field controllers,supervisory controllers, actuators, temperature sensors, and otherdevices for controlling the temperature, humidity, airflow, or othervariable conditions within building 10. Lighting subsystem 442 caninclude any number of light fixtures, ballasts, lighting sensors,dimmers, or other devices configured to controllably adjust the amountof light provided to a building space. Security subsystem 438 caninclude occupancy sensors, video surveillance cameras, digital videorecorders, video processing servers, intrusion detection devices, accesscontrol devices (e.g., card access, etc.) and servers, or othersecurity-related devices.

Still referring to FIG. 4, BMS controller 366 is shown to include acommunications interface 407 and a BMS interface 409. Interface 407 canfacilitate communications between BMS controller 366 and externalapplications (e.g., monitoring and reporting applications 422,enterprise control applications 426, remote systems and applications444, applications residing on client devices 448, etc.) for allowinguser control, monitoring, and adjustment to BMS controller 366 and/orsubsystems 428. Interface 407 can also facilitate communications betweenBMS controller 366 and client devices 448. BMS interface 409 canfacilitate communications between BMS controller 366 and buildingsubsystems 428 (e.g., HVAC, lighting security, lifts, powerdistribution, business, etc.).

Interfaces 407, 409 can be or include wired or wireless communicationsinterfaces (e.g., jacks, antennas, transmitters, receivers,transceivers, wire terminals, etc.) for conducting data communicationswith building subsystems 428 or other external systems or devices. Invarious embodiments, communications via interfaces 407, 409 can bedirect (e.g., local wired or wireless communications) or via acommunications network 446 (e.g., a WAN, the Internet, a cellularnetwork, etc.). For example, interfaces 407, 409 can include an Ethernetcard and port for sending and receiving data via an Ethernet-basedcommunications link or network. In another example, interfaces 407, 409can include a Wi-Fi transceiver for communicating via a wirelesscommunications network. In another example, one or both of interfaces407, 409 can include cellular or mobile phone communicationstransceivers. In one embodiment, communications interface 407 is a powerline communications interface and BMS interface 409 is an Ethernetinterface. In other embodiments, both communications interface 407 andBMS interface 409 are Ethernet interfaces or are the same Ethernetinterface.

Still referring to FIG. 4, BMS controller 366 is shown to include aprocessing circuit 404 including a processor 406 and memory 408.Processing circuit 404 can be communicably connected to BMS interface409 and/or communications interface 407 such that processing circuit 404and the various components thereof can send and receive data viainterfaces 407, 409. Processor 406 can be implemented as a generalpurpose processor, an application specific integrated circuit (ASIC),one or more field programmable gate arrays (FPGAs), a group ofprocessing components, or other suitable electronic processingcomponents.

Memory 408 (e.g., memory, memory unit, storage device, etc.) can includeone or more devices (e.g., RAM, ROM, Flash memory, hard disk storage,etc.) for storing data and/or computer code for completing orfacilitating the various processes, layers and modules described in thepresent application. Memory 408 can be or include volatile memory ornon-volatile memory. Memory 408 can include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present application. According to an exampleembodiment, memory 408 is communicably connected to processor 406 viaprocessing circuit 404 and includes computer code for executing (e.g.,by processing circuit 404 and/or processor 406) one or more processesdescribed herein.

In some embodiments, BMS controller 366 is implemented within a singlecomputer (e.g., one server, one housing, etc.). In various otherembodiments BMS controller 366 can be distributed across multipleservers or computers (e.g., that can exist in distributed locations).Further, while FIG. 4 shows applications 422 and 426 as existing outsideof BMS controller 366, in some embodiments, applications 422 and 426 canbe hosted within BMS controller 366 (e.g., within memory 408).

Still referring to FIG. 4, memory 408 is shown to include an enterpriseintegration layer 410, an automated measurement and validation (AM&V)layer 412, a demand response (DR) layer 414, a fault detection anddiagnostics (FDD) layer 416, an integrated control layer 418, and abuilding subsystem integration later 420. Layers 410-420 can beconfigured to receive inputs from building subsystems 428 and other datasources, determine optimal control actions for building subsystems 428based on the inputs, generate control signals based on the optimalcontrol actions, and provide the generated control signals to buildingsubsystems 428. The following paragraphs describe some of the generalfunctions performed by each of layers 410-420 in BMS 400.

Enterprise integration layer 410 can be configured to serve clients orlocal applications with information and services to support a variety ofenterprise-level applications. For example, enterprise controlapplications 426 can be configured to provide subsystem-spanning controlto a graphical user interface (GUI) or to any number of enterprise-levelbusiness applications (e.g., accounting systems, user identificationsystems, etc.). Enterprise control applications 426 can also oralternatively be configured to provide configuration GUIs forconfiguring BMS controller 366. In yet other embodiments, enterprisecontrol applications 426 can work with layers 410-420 to optimizebuilding performance (e.g., efficiency, energy use, comfort, or safety)based on inputs received at interface 407 and/or BMS interface 409.

Building subsystem integration layer 420 can be configured to managecommunications between BMS controller 366 and building subsystems 428.For example, building subsystem integration layer 420 can receive sensordata and input signals from building subsystems 428 and provide outputdata and control signals to building subsystems 428. Building subsystemintegration layer 420 can also be configured to manage communicationsbetween building subsystems 428. Building subsystem integration layer420 translate communications (e.g., sensor data, input signals, outputsignals, etc.) across a plurality of multi-vendor/multi-protocolsystems.

Demand response layer 414 can be configured to optimize resource usage(e.g., electricity use, natural gas use, water use, etc.) and/or themonetary cost of such resource usage in response to satisfy the demandof building 10. The optimization can be based on time-of-use prices,curtailment signals, energy availability, or other data received fromutility providers, distributed energy generation systems 424, fromenergy storage 427 (e.g., hot TES 242, cold TES 244, etc.), or fromother sources. Demand response layer 414 can receive inputs from otherlayers of BMS controller 366 (e.g., building subsystem integration layer420, integrated control layer 418, etc.). The inputs received from otherlayers can include environmental or sensor inputs such as temperature,carbon dioxide levels, relative humidity levels, air quality sensoroutputs, occupancy sensor outputs, room schedules, and the like. Theinputs can also include inputs such as electrical use (e.g., expressedin kWh), thermal load measurements, pricing information, projectedpricing, smoothed pricing, curtailment signals from utilities, and thelike.

According to an example embodiment, demand response layer 414 includescontrol logic for responding to the data and signals it receives. Theseresponses can include communicating with the control algorithms inintegrated control layer 418, changing control strategies, changingsetpoints, or activating/deactivating building equipment or subsystemsin a controlled manner. Demand response layer 414 can also includecontrol logic configured to determine when to utilize stored energy. Forexample, demand response layer 414 can determine to begin using energyfrom energy storage 427 just prior to the beginning of a peak use hour.

In some embodiments, demand response layer 414 includes a control moduleconfigured to actively initiate control actions (e.g., automaticallychanging setpoints) which minimize energy costs based on one or moreinputs representative of or based on demand (e.g., price, a curtailmentsignal, a demand level, etc.). In some embodiments, demand responselayer 414 uses equipment models to determine an optimal set of controlactions. The equipment models can include, for example, thermodynamicmodels describing the inputs, outputs, and/or functions performed byvarious sets of building equipment. Equipment models can representcollections of building equipment (e.g., subplants, chiller arrays,etc.) or individual devices (e.g., individual chillers, heaters, pumps,etc.).

Demand response layer 414 can further include or draw upon one or moredemand response policy definitions (e.g., databases, XML files, etc.).The policy definitions can be edited or adjusted by a user (e.g., via agraphical user interface) so that the control actions initiated inresponse to demand inputs can be tailored for the user's application,desired comfort level, particular building equipment, or based on otherconcerns. For example, the demand response policy definitions canspecify which equipment can be turned on or off in response toparticular demand inputs, how long a system or piece of equipment shouldbe turned off, what setpoints can be changed, what the allowable setpoint adjustment range is, how long to hold a high demand setpointbefore returning to a normally scheduled setpoint, how close to approachcapacity limits, which equipment modes to utilize, the energy transferrates (e.g., the maximum rate, an alarm rate, other rate boundaryinformation, etc.) into and out of energy storage devices (e.g., thermalstorage tanks, battery banks, etc.), and when to dispatch on-sitegeneration of energy (e.g., via fuel cells, a motor generator set,etc.).

Integrated control layer 418 can be configured to use the data input oroutput of building subsystem integration layer 420 and/or demandresponse later 414 to make control decisions. Due to the subsystemintegration provided by building subsystem integration layer 420,integrated control layer 418 can integrate control activities of thesubsystems 428 such that the subsystems 428 behave as a singleintegrated super system. In an example embodiment, integrated controllayer 418 includes control logic that uses inputs and outputs from aplurality of building subsystems to provide greater comfort and energysavings relative to the comfort and energy savings that separatesubsystems could provide alone. For example, integrated control layer418 can be configured to use an input from a first subsystem to make anenergy-saving control decision for a second subsystem. Results of thesedecisions can be communicated back to building subsystem integrationlayer 420.

Integrated control layer 418 is shown to be logically below demandresponse layer 414. Integrated control layer 418 can be configured toenhance the effectiveness of demand response layer 414 by enablingbuilding subsystems 428 and their respective control loops to becontrolled in coordination with demand response layer 414. Thisconfiguration may advantageously reduce disruptive demand responsebehavior relative to conventional systems. For example, integratedcontrol layer 418 can be configured to assure that a demandresponse-driven upward adjustment to the setpoint for chilled watertemperature (or another component that directly or indirectly affectstemperature) does not result in an increase in fan energy (or otherenergy used to cool a space) that would result in greater total buildingenergy use than was saved at the chiller.

Integrated control layer 418 can be configured to provide feedback todemand response layer 414 so that demand response layer 414 checks thatconstraints (e.g., temperature, lighting levels, etc.) are properlymaintained even while demanded load shedding is in progress. Theconstraints can also include setpoint or sensed boundaries relating tosafety, equipment operating limits and performance, comfort, fire codes,electrical codes, energy codes, and the like. Integrated control layer418 is also logically below fault detection and diagnostics layer 416and automated measurement and validation layer 412. Integrated controllayer 418 can be configured to provide calculated inputs (e.g.,aggregations) to these higher levels based on outputs from more than onebuilding subsystem.

Automated measurement and validation (AM&V) layer 412 can be configuredto verify that control strategies commanded by integrated control layer418 or demand response layer 414 are working properly (e.g., using dataaggregated by AM&V layer 412, integrated control layer 418, buildingsubsystem integration layer 420, FDD layer 416, or otherwise). Thecalculations made by AM&V layer 412 can be based on building systemenergy models and/or equipment models for individual BMS devices orsubsystems. For example, AM&V layer 412 can compare a model-predictedoutput with an actual output from building subsystems 428 to determinean accuracy of the model.

Fault detection and diagnostics (FDD) layer 416 can be configured toprovide on-going fault detection for building subsystems 428, buildingsubsystem devices (i.e., building equipment), and control algorithmsused by demand response layer 414 and integrated control layer 418. FDDlayer 416 can receive data inputs from integrated control layer 418,directly from one or more building subsystems or devices, or fromanother data source. FDD layer 416 can automatically diagnose andrespond to detected faults. The responses to detected or diagnosedfaults can include providing an alert message to a user, a maintenancescheduling system, or a control algorithm configured to attempt torepair the fault or to work-around the fault.

FDD layer 416 can be configured to output a specific identification ofthe faulty component or cause of the fault (e.g., loose damper linkage)using detailed subsystem inputs available at building subsystemintegration layer 420. In other example embodiments, FDD layer 416 isconfigured to provide “fault” events to integrated control layer 418which executes control strategies and policies in response to thereceived fault events. According to an example embodiment, FDD layer 416(or a policy executed by an integrated control engine or business rulesengine) can shut-down systems or direct control activities around faultydevices or systems to reduce energy waste, extend equipment life, orassure proper control response.

FDD layer 416 can be configured to store or access a variety ofdifferent system data stores (or data points for live data). FDD layer416 can use some content of the data stores to identify faults at theequipment level (e.g., specific chiller, specific AHU, specific terminalunit, etc.) and other content to identify faults at component orsubsystem levels. For example, building subsystems 428 can generatetemporal (i.e., time-series) data indicating the performance of BMS 400and the various components thereof. The data generated by buildingsubsystems 428 can include measured or calculated values that exhibitstatistical characteristics and provide information about how thecorresponding system or process (e.g., a temperature control process, aflow control process, etc.) is performing in terms of error from itssetpoint. These processes can be examined by FDD layer 416 to exposewhen the system begins to degrade in performance and alert a user torepair the fault before it becomes more severe.

Involvement User Interface

Referring now to FIG. 5, a block diagram of a server 500 associated withBMS 400 is shown, according to some embodiments. Server 500 can beconfigured to generate and present an involvement user interface to auser of BMS 400 on a user device 540. The involvement user interfacegenerally allows the user to view logical relationships between buildingobjects in an intuitive, user-friendly manner. This functionality mayallow users to achieve a better understanding of logical relationshipswithin BMS 400, thereby leading to improved efficiency for the user withrespect to system configuration and troubleshooting. The involvementuser interface may present a selected object near the center of the userinterface, in addition to presenting input objects that affect theselected object and output objects that are affected by the selectedobject on opposing sides of the user interface. In this manner, the usermay easily view all logical relationships associated with the selectedobject in a single view.

Server 500 can be implemented within BMS 400 in a variety of ways. Forexample, server 500 may be a network device such as a network engine ora controller such as BMS controller 366. Server 500 may also be aworkstation, personal computer or another type of device similar toclient device 368 with server software installed thereon. Server 500 mayalso be implemented using one or more on-premises server computersand/or one or more remote cloud-based server computers. In this sense,server 500 may be distributed across a variety of physical hardwaredevices. Server 500 may generally provide services for various clientdevices associated with BMS 400. Server 500 is shown to include aprocessing circuit 510 that includes a processor 512 and a memory 520.It will be appreciated that these components can be implemented using avariety of different types and quantities of processors and memory.Server 500 is also shown to include a communications interface 530configured to send data to and receive data from user device 540.Communications interface 530 may also be in communication with equipmentof BMS 400 such as BMS controller 366. For example, communicationsinterface 530 may include a wired and/or wireless BACnet interface inaddition to other types of communications interfaces (e.g., Modbus,LonWorks, DeviceNet, WL, etc.).

User device 540 may be any electronic device that allows a user tointeract with BMS 400 through a user interface. Examples of user devicesinclude, but are not limited to, mobile phones, electronic tablets,laptops, desktop computers, workstations, and other types of electronicdevices. User device 540 may be similar to client device 368 asdescribed above. User device 540 may display the involvement userinterface on a display, thereby enabling a user to easily view andtroubleshoot objects associated with BMS 400.

Memory 520 is shown to include a BMS database 522 that can be configuredto store a variety of data associated with BMS 400. For example, BMSdatabase 522 can generally maintain historical data including trenddata, event data, alarm data, operator transaction data, as well assystem configuration data. System configuration data can includeconfiguration data related to spaces, equipment, points, controllers,network engines, and other configuration data related to BMS 400. Thehistorical data maintained by BMS database 522 may generally beassociated with any of the equipment described above. For example, BMSdatabase 522 may include sensor readings and other data associated withBMS 400. BMS server 500 can access data from BMS database 522 in orderto generate and present the involvement user interface to a user. Itwill be appreciated that BMS database 522 can be implemented as a singledatabase or multiple separate databases working together.

BMS 400 can generally be configured to access and manipulate data usingan object-oriented approach. For example, BMS 400 may utilize a varietyof different types of objects to perform functions such as automatedmeasurement and validation, demand response, fault detection anddiagnostics, and other functions such as described above. Each objectcan include associated attributes and methods representative of physicalequipment and devices in building 10. Objects associated with BMS 400can interact with each other and can be stored and maintained in BMSdatabase 522. In this manner, objects can be used to control equipmentof BMS 400. Software defined building objects are described in moredetail in U.S. patent application Ser. No. 12/887,390, filed Sep. 21,2010, the entirety of which is incorporated by reference herein.

Memory 520 is also shown to include a data collector 524 that can beconfigured to collect and format data associated with BMS 400. Forexample, data collector 524 can be configured to collect live data frombuilding equipment (e.g., via communications interface 530) such asreal-time readings from a temperature sensor, flow sensor, supply fan,etc., which may include a current state or value (e.g., true, false,off, temperature, flow rate, etc.). Data collector 524 may also retrievehistorical data (e.g., trend data, event data, alarm data, operatortransaction data, system configuration data, etc.) and reference objectsfrom BMS database 522.

Memory 520 is also shown to include a relationship analyzer 526.Relationship analyzer 526 can be configured to analyze and identifylogical relationships between two or more objects. In some embodiments,logical relationships between objects may include commands (e.g.,“commanded by”, “commands”), references (e.g., “referenced by”,“references”), or other functions (e.g., “written to”, “writes”). Forexample, relationship analyzer 526 may analyze a first object (e.g., aschedule object) and a second object (e.g., a photocell object) anddetermine that the first object is commanding the second object toperform an action (e.g., turn photocells on). Relationship analyzer 526may also identify the priority array associated with the objectrelationship. To continue the previous example, the first object maycommand the second object to perform the action at priority value of 6,while a third object (e.g., an interlock object) may command the secondobject to perform another action (e.g., turn photocells off) at a higherpriority value of 3. The logical relationships analyzed and identifiedby relationship analyzer 526 can be used to populate a relationship treeand may be compiled for presentation on the user device 540.

Memory 520 is also shown to include a user interface generator 528. Userinterface generator 528 may be configured to generate the involvementuser interface that may be presented on user device 540. User interfacegenerator 528 may utilize a diagramming library (e.g., yFiles, JGraph,Mermaid, Rappid, etc.) and/or other similar method to generate theinvolvement user interface, for example. The involvement user interfacemay include objects, object properties (e.g., object name, objectidentifier, object type, object address, object status, object state,etc.), and connectors that illustrate the logical relationships betweenobjects. User interface generator 528 may retrieve information on objectproperties from data collector 524 and may retrieve information logicalrelationships between objects from relationship analyzer 526. Userinterface generator 528 may be implemented as a webserver that canstore, process, and deliver web pages (e.g., HTML documents) to a webbrowser of a user device 540, or as an application on a user device 540(e.g., desktop application, mobile application), for example. Userinterface generator 528 may generally receive inputs (e.g., HTTPrequests) from user device 540.

In some embodiments, user interface generator 528 may present objects inthe form of graphical elements, such as object blocks. Logicalrelationships between objects may be presented in the form of connectors(e.g., lines, arrows) between object blocks. Object blocks andconnectors presented via the involvement user interface may includetextual or graphical representations of information such as objectproperties (e.g., object name, object identifier, object address, objectcondition, object state, etc.), logical relationship types (e.g.,commands, references, functions), and priorities, as shown for examplein FIG. 6, described in more detail below. For example, user interfacegenerator 528 may present an object (e.g., an interlock object) via theinvolvement user interface. The object may be presented in the form ofan object block, where the object block includes the object name, theobject type, the object's current condition and status, and the objectaddress. Object blocks and the information contained therein may beselectable by a user of user device 540, such that selecting the blockdisplays additional information about the object properties. The objectblock may also include a link which, after being selected by a user ofuser device 540, presents additional properties of the selected objectblock or navigates the user to a page associated with the object. Fromthis object page, the user may view more detailed information about theobject and make edits to various properties associated with the object.In other embodiments, the user interface generator 528 may presentobjects in using textual or graphical representations other than objectblocks and connectors.

In another example, user interface generator 528 may present threeobject blocks on the involvement user interface. If a first object blockcommands a second object block, the logical relationship between theobject blocks may be identified as “commands” on a connector shownbetween the first and second object blocks on the user interface. If athird object block is referenced by the second object block, the logicalrelationship between the object blocks may be identified as “referencedby” on a connector shown between the second and third object blocks onthe user interface. A user of user device 540 may view additionalinformation about the logical relationship between the objects blocks byselecting the connector or, in some embodiments, an information iconnear the connector. Upon receiving a user selection of the connector (orinformation icon) between two objects, the user interface generator maypresent the priorities associated with the relationship between the twoobjects. The ability to view object relationships, including details onobject logical relationships (e.g., priority), may allow administratorsto more efficiently troubleshoot objects associated with BMS 400 byquickly identifying where a problem may exist and how related objectsmay impact the problem objects.

In some embodiments, user interface generator 528 may provide a user ofuser device 540 with a progressive disclosure of information relating toobject blocks and/or logical relationship connectors between objectblocks. Progressive disclosure allows the user to zoom-in and zoom-outon the involvement user interface, thereby being presented with more orless information relating to the object blocks and/or logicalrelationship connectors presented on the involvement user interface. Forexample, the user may zoom-out on the involvement user interface to viewa plurality of object blocks and the logical relationship connectorsbetween the object blocks being presented. The user may then zoom-in onan object block, or a logical relationship connector between two objectblocks, to view additional information about said object block orlogical relationship connector. In this example, a user may be presentedwith limited information when the involvement user interface iszoomed-out (e.g., the object block includes only one of the object'sname, type, current condition and status, or address), and informationmay be added to the involvement user interface as the user zooms-in(e.g., one or more of the object's name, type, current condition andstatus, or address, not previously presented, are presented via theinvolvement user interface).

Referring now to FIG. 6, an example involvement user interface 600 isshown, according to some embodiments. Interface 600 can be presented onuser device 540 by BMS server 500, for example. Interface 600 is shownto include a plurality of objects associated with BMS 400 and logicalrelationships therebetween. Interface 600 may allow a user of userdevice 540 to quickly identify an object's properties, the input andoutput objects that impact it, and the logical relationships betweenthese objects. By presenting this information in a single display, usersmay be able to troubleshoot BMS 400 more efficiently, thereby removingthe need to navigate through various user interface screens to finddesired object information. As described above, a user may be able tozoom-in and zoom-out on interface 600 to view more or less informationabout each of the object blocks and logical relationships connectionspresented.

Interface 600 is shown to include an interlock object 610 that ispresented at or near the center of interface 600. Interlock object 610may be a “selected object” that is selected by the user because the userwishes to view logical relationships associated with interlock object610. Interface 600 presents both input objects that affect interlockobject 610 as well as output objects that are affected by interlockobject 610. The input objects and the output objects are presented onopposing sides of interlock object 610 interface 600. In this manner,the user can easily view all logical relationships associated withinterlock object 610 in a single view.

Interlock object 610 may generally provide a means for establishingconditional control over one or more other objects. As shown ininterface 600, interlock object 610 establishes conditional control overmultiple light scene objects (as discussed in more detail below).Interlock object 610 may include a conditional statement as well as truecommand statements and false command statements to specify a set ofconditional checks for which commands are used to control the lightscene objects. Interlock object 610 may also be affected by otherobjects such as a schedule object (as discussed in more detail below).In some previous approaches, users may struggle to identify each of theobjects affected by interlock object 610 as well as each of the objectsthat affect interlock object 610.

As shown, interface 600 may present various information associated withinterlock object 610 such as an object identifier (“Interlock”), anobject name (“Bridge Ramp Photocell Interlock”), a current status(“Trouble”), current state or value (“False”), current priority(“Priority: 14”), an object address (e.g., in BMS database 522), a space(“Building A>5757>Bridge”), and one or more links that allow the user tonavigate to a settings page associated with interlock object 610(“Bridge Lights”). In this manner, interface 600 not only allows theuser to view logical relationships associated with interlock object 610,but it also allows the user to view a variety of information aboutinterlock object 610 and provides an efficient means for editingsettings associated with interlock object 610.

As shown, interface 600 presents logical relationships between objectusing different types of connectors. For example, interface 600 is shownto include a connector indicating that a lighting schedule object 622writes to interlock object 610. Interface 600 is also shown to include aconnector indicating that a cleaning control object 624 is referenced byinterlock object 610 and a connector indicating that a parking photocellobject 626 is referenced by interlock object 610. Further, interface 600is shown to include a connector indicating that a light scene object 632is commanded by interlock object 610, a connector indicating thatanother light scene object 634 is commanded by interlock object 610, aconnector indicating that yet another light scene object 636 iscommanded by interlock object 610, and a connector indicating thatanother interlock object 638 references interlock object 610. Notably,the objects that affect interlock object 610 (e.g., input objects) arepresented on the left side of interlock object 610 and the objects thatare affected by interlock object 610 (e.g., output objects) arepresented on the right side of interlock object 610 on interface 600.

In some embodiments, when an output (e.g., a state or value) of a firstobject block is equivalent to the input of the selected object block, alogical relationship connector between the two objects blocks may bepresented as a bold line. For example, and as shown in interface 600,lighting schedule object 622 writes to interlock object 610. The boldlogical relationship connector between lighting schedule object 622 andinterlock object 610 indicates that the current state or value oflighting schedule object 622 (“False”) is being written to interlockobject 610, shown with a current state or value of “False.” In someembodiments, an object block may be highlighted (e.g., made bold) toindicate that the object block is pushing an output state or value thatis equivalent to the input of another object block. For example, if anoccupancy object has a current state of “Occupied,” a schedule objectthat is writing “Occupied” to the occupancy object may be highlighted.Any type of visual indication that accentuates a connector betweenobjects with an equivalent state or value may be presented on theinvolvement user interface.

Similar to interlock object 610, interface 600 is shown to present avariety of information associated with each input object and each outputobject associated with interlock object 610. For example, lightingschedule object 622 is shown to include an object identifier(“Schedule”), an object name (“Bridge Ramp Lighting Schedule”), acurrent status (“Normal”), a current state or value (“False”), and anobject address (e.g., in BMS database 522). Lighting schedule object 622may generally provide a means for updating the attributes of one or moreother objects at specified times, days, and dates. Lighting scheduleobject 622 may include a time/value pair that describes the time, day,or date that an attribute of another object changes to a defined stateor value. As shown in interface 600, lighting schedule object 622updates the attributes of interlock object 610 by writing a state orvalue to interlock object 610.

Interface 600 is also shown to present a variety of informationassociated with cleaning control object 624 including an objectidentifier (“Cleaning—Control”), an object name (“Cleaning Lights On—OffControl”), a current status (“Normal”), a current state or value(“Off”), and an object address (e.g., in BMS database 522). Cleaningcontrol object 624 may generally be a command object, providing a meansfor controlling one or more other objects, such as multiple photocells(e.g., cleaning lights). Cleaning control object 624 may include a stateor value (e.g., on/off) that commands the value or state of one or moreother objects to that state or value. For example, cleaning controlobject 624 may command multiple photocells (“cleaning lights”) to the“on” state. As shown in interface 600, cleaning control object 624 isreferenced by interlock object 610.

Interface 600 is also shown to present a variety of informationassociated with parking photocell object 626 including an objectidentifier (“Parking—Photocell”), an object name (“Parking PhotocellLights”), a current status (“Normal”), a current state or value(“Night”), and an object address (e.g., in BMS database 522). Parkingphotocell object 626 may generally be a command object, providing ameans for controlling one or more other objects, such as multiplephotocells (e.g., parking photocell lights). Parking photocell object626 may include a state or value (e.g., day/night) that commands thevalue or state of one or more other objects to that state or value. Forexample, parking photocell object 626 may command multiple photocells(“parking photocell lights”) to the “night” state, where “night” may bea predefined state or value for one or more photocell objects controlledby the parking photocell object 626. As shown in interface 600, parkingphotocell object 626 is referenced by interlock object 610.

Light scene objects 632-636 are shown to include an object identifier(“Set-Scene”), an object name (e.g., “Lighting Set Scene Space ID 17Bridge”), a current status (“Normal”), a current state or value (“State4”), and an object address (e.g., in BMS database 522). Light sceneobjects 632-636 may generally be multi-state value objects that set astatic or dynamic value for multiple light fixtures in a space (e.g., aroom in building 10). For example, light scene object 632 may write orcommand a value, “State 4,” to all of the light fixtures of “space ID17.” As shown in interface 600, interlock object 610 commands lightscene objects 632-636.

Interlock object 638 is shown to include an object identifier(“Interlock”), an object name (“Interlock 4”), a current status(“Normal”), a current state or value (“True”), and an object address(e.g., in BMS database 522). Similar to interlock object 610, interlockobject 638 may generally provide a means for establishing conditionalcontrol over one or more other objects. As shown in interface 600,interlock object 638 is referenced by interlock object 610.

Referring now to FIG. 7, another example involvement user interface 700is shown, according to some embodiments. Interface 700 may be presentedby BMS server 500 on user device 540, for example. Interface 700 may bepresented to the user after the user selects light scene object 632 viainterface 600. Responsive to receiving this user input consisting of aselection of light scene object 632, BMS server 500 may update theinvolvement user interface such that light scene object 632 becomes thenew selected object. In this manner, the user can now easily view alllogical relationships associated with light scene object 632. Interface700 is shown to include an analog output object 732 that is commanded bylight scene object 632. Accordingly, interface 700 is shown to include aconnector indicating that that analog output object 732 is commanded bylight scene object 632. Interface 700 is also shown to include interlockobject 610 and a connector indicating that light scene object 632 iscommanded by interlock object 610.

In becoming the new selected object, BMS server 500 may presentadditional information regarding light scene object 632 in interface 700than presented in interface 600. For example, light scene object 632 isshown to include an indication of priority (e.g., “Priority: 14”) ininterface 700, but not in interface 600. Additionally, BMS server 500may present less information about objects that have been “unselected”such as interlock object 610 as shown in interface 700. For example,interlock object 610 as shown in interface 700 does not include priorityinformation or space information as was shown in interface 600 sinceinterlock object 610 is no longer the selected object.

Referring now to FIG. 8, another example involvement user interface 800showing an example of priority is shown, according to some embodiments.Interface 800 may be presented by BMS server 500 on user device 540, forexample. It will be appreciated that interface 800 only shows a portionof a full involvement user interface and is intended to show an exampleof priority functionality. Interface 800 may be displayed when the userselects a connection between two objects. For example, a connector mayinclude an information icon 840 as shown in interface 800. The user mayselect information icon 840 in order to view information about theconnection between two objects. After receiving the user input includinga selection of information icon 840, as shown in interface 800, BMSserver 500 may present a text box 842 that presents details about thelogical relationship indicated by the connector. Details presented intext box 842 may include priorities, the values that one object iswriting to another, the data that one object is commanding to another,the information that one object references from another, and otherinformation. For example, a first object may command a second object toset the second object's state to “on” at priority 4 in a priority array.In some embodiments, text box 842 is an interactive dialog box that theuser can interact with in order to affect the logical relationshipindicated by the connector.

In allowing the user to view information regarding logical relationshipsbetween objects via interface 800, such as the priority arrayinformation shown in text box 842, the involvement user interface mayfacilitate improved troubleshooting and system management capabilities.Interface 800 may allow the user to quickly determine how two objectsare interacting and view information on priority array data on suchobject interactions. Priority array information may be beneficial tousers when troubleshooting or interacting with BMS 400 by allowing usersto determine what values and/or states are being commanded and/orwritten, and at what priority these values and/or states are beingcommanded and/or written. For example, problems may arise if twodifferent states or values (e.g., “State (0)” and “State (4)”) arecommanded at the same priority level (e.g., “Priority 15”). Interface800 may allow a user to quickly identify and correct this discrepancy.

Referring now to FIG. 9, another example involvement user interface 900showing an example of an unbound object 952 is shown, according to someembodiments. Interface 900 may be presented by BMS server 500 on userdevice 540, for example. It will be appreciated that interface 900 onlyshows a portion of a full involvement user interface and is intended toshow an example of unbound object functionality. Similar to otherobjects presented on the involvement user interface, a variety ofattributes may be presented with unbound object 952 such as an objectidentifier (“Unbound”), an object name (“Example”), and an objectaddress (e.g., in BMS database 522). However, unlike other objectpresented on the involvement user interface, unbound object 952 may bepresented using dotted lines as shown in interface 900 or other similarvisual indications alerting the user of the unbound object. As shown ininterface 900, the connector associated with unbound object 952 may alsobe presented as a dotted line.

Interface 900 may be presented when a user selects an object that hasbeen moved or deleted (e.g., within BMS database 522), thereby causingthe object link to become invalid. Interface 900 may also be presentedwhen a selected object has a logical relationship with an unbound object(e.g., an input or output object of a selected object). Unbound objectsare generally objects that are not bound in BMS 400, such that theobject and/or object properties cannot be located due to the object'sreference within the system being incorrect (e.g., having been moved ordeleted). In this sense, unbound objects may be invalid objects thatunintentionally affect other, valid objects, thereby unnecessarilyconsuming memory or other system resources. References to unboundobjects may have been valid at a previous time, however may no longer bevalid.

Interface 900 may aid a user in troubleshooting a problem object byidentifying unbound objects which may be affecting the problem object.For example, a selected object may reference an unbound object, therebycausing a problem with the selected object, as the unbound object hasbeen moved or deleted and the reference, therefore, is no longer valid.Additionally, the involvement user interface may allow the user to“clean-up” invalid objects and object references (e.g., by removing fromBMS database 522). For example, the user may choose to delete unboundobjects that are connected to a selected object, as the logicalrelationship between the selected object and the unbound object isunnecessary, such that unbound objects cannot be commanded or written toby the selected object. The user may be unaware such that unboundobjects exists before interacting with the involvement user interface.

Referring now to FIG. 10, an example process 1000 for presenting logicalrelationships between objects in a BMS to a user via a user interface isshown, according to some embodiments. Process 1000 can be performed byBMS server 500 in communication with a user via user device 540, and theuser interface may be the involvement user interface as described above,for example. Process 1000 generally provides the user with the abilityto navigate through object relationships efficiently, thereby allowingthe user to identify how objects impact one another and providingtraceability though BMS 400. As discussed above, the involvement userinterface generally includes a plurality of objects associated with BMS400 and logical relationships therebetween. The involvement userinterface may allow a user to quickly identify object properties, theinput and output objects that impact it, and the logical relationshipsbetween objects.

Process 1000 is shown to include identifying a first object that isselected by the user (step 1002). For example, the first object may beinterlock object 610 (e.g., the selected object) as described above. Auser may select the first object as part of a troubleshooting procedurewhen building equipment (e.g., subplants, chiller arrays, etc.) orindividual devices (e.g., individual chillers, heaters, pumps, etc.) arenot functioning properly. For example, a section of bridge lights may beoperating incorrectly (e.g., at an incorrect state or value, in atrouble status, etc.), prompting the user to inspect building objectswhich are known to affect the bridge lights. In this example, the usermay select interlock object 610, which is named “Bridge Ramp PhotocellInterlock,” and generally provides means for establishing conditionalcontrol over one or more other objects (e.g., bridge ramp photocells),to begin the troubleshooting process.

Process 1000 is also shown to include identifying input objects andoutput objects associated with the first object (step 1004). Forexample, step 1004 may include identifying lighting schedule object 622,cleaning control object 624, and parking photocell object 626, asdescribed above, as input objects associated with interlock object 610.Step 1004 may also include identifying light scene objects 632-636 andinterlock object 638, as described above, as output objects associatedwith interlock object 610. Generally, the input objects are objects thataffect the first object and the output objects are objects that areaffected by the first object. For example, lighting schedule object 622writes to interlock object 610, and light scene object 632 is commandedby interlock object 610. Identifying objects in step 1004 may alsoinclude identifying object properties for each of the input objects andthe output objects, such as the object name, identifier, type, status,value, address, and/or other properties or information. Step 1004 may beperformed by relationship analyzer 526 by accessing BMS database 522,for example.

Process 1000 is also shown to include presenting an involvement userinterface to the user on a user device, the involvement user interfaceincluding the input objects and the output objects associated with thefirst object on opposing sides of the first object (step 1006). Forexample, referring back to FIG. 6, interlock object 610 (e.g., the firstobject) is shown at or near the center of interface 600. The inputobjects associated with interlock object 610, including lightingschedule object 622, cleaning control object 624, and parking photocellobject 626, may be presented on the left side of interlock object 610.The output objects, including light scene objects 632-636 and interlockobject 638, may be presented on the right side of interlock object 610.Additionally, the logical relationships and associated connectorsbetween objects may be presented at step 1006. For example, referringagain back to FIG. 6, various connectors) are shown between objects thatidentify logical relationships between the objects as discussed above.The involvement user interface may also provide priority and unboundobject functionality as described above with reference to FIG. 8 andFIG. 9.

Process 1000 is also shown to include receiving an input from the uservia the involvement user interface including a selection of a secondobject, wherein the second object is one of the input objects or one ofthe output objects associated with the first object (step 1008). Forexample, the user may be troubleshooting bridge lights that are notfunctioning correctly and, after selecting interlock object 610, theuser may learn that light scene objects 632 is commanded by interlockobject 610. The bridge lights that are not functioning correctly may belocalized to a space, such as “Space ID 17.” A user may identify, viainterface 600, that light scene object 632 is identified as a“Set-Scene” object for “Space ID 17,” and subsequently select lightscene object 632 to view additional object properties and informationassociated with light scene object 632.

Process 1000 is also shown to include identifying input objects andoutput objects associated with the second object (step 1010). Forexample, after selecting light scene object 632, the input objects, suchas interlock object 610, and output objects, such as analog outputobject 732, may be identified. Similar to step 1004, the input objectsare generally objects that affect the second object and the outputobjects are generally objects that are affected by the second object.For example, interlock object 610 commands light scene object 632, andanalog output object 732 is commanded by light scene object 632.Identifying objects at step 1010 may also include identifying objectproperties for each of the input and output objects, such as the objectname, identifier, type, status, value, address, and/or other propertiesor information.

Process 1000 is also shown to include updating the involvement userinterface such that input objects and output objects associated with thesecond object are shown (step 1012). For example, BMS server 500 maygenerate interface 700 after receiving the user selection of light sceneobject 632. Interface 700 is shown to include the second object (lightscene 632) at or near the center of the interface, with the input object(interlock object 610) on the left side of light scene object 632 andthe output object (analog output object 732) on the right side of lightscene object 632. Additionally, the logical relationships between theseobjects may be presented as connectors between the object blocks. Forexample, an arrow is shown between light scene object 632 and analogoutput object 732, indicating that light scene object 632 commandsanalog output object 732.

The steps of process 1000 may be repeated as the user continues toselect different objects. In this manner, a user can easily viewrelevant object properties and logical relationships associated with theselected object. Process 1000 provides object properties andrelationships in an intuitive, single-page overview, thereby removingthe need to navigate through various user interface screens to finddesired object information. Process 1000 may allow users to achieve abetter understanding of logical relationships between objects within aBMS, thereby leading to improved efficiency with respect to systemconfiguration and troubleshooting.

While the involvement user interface as described herein refers topresentation of objects such as BACnet objects, it will be appreciatedthat a similar approach may be used in systems that do not use anobject-oriented approach. For example, a building management system mayimplement open-source protocols such as Brick Schema and ProjectHaystack to define building entities. In this example, the involvementuser interface may present relationships between Brick Schema entities,and not necessarily “objects” as discussed herein. The use of the term“objects” is not intended to be limiting, and minor variations thereofare contemplated within the scope of this disclosure.

CONFIGURATION OF EXEMPLARY EMBODIMENTS

The construction and arrangement of the systems and methods as shown inthe various exemplary embodiments are illustrative only. Although only afew embodiments have been described in detail in this disclosure, manymodifications are possible (e.g., variations in sizes, dimensions,structures, shapes and proportions of the various elements, values ofparameters, mounting arrangements, use of materials, colors,orientations, etc.). For example, the position of elements may bereversed or otherwise varied and the nature or number of discreteelements or positions may be altered or varied. Accordingly, all suchmodifications are intended to be included within the scope of thepresent disclosure. The order or sequence of any process or method stepsmay be varied or re-sequenced according to alternative embodiments.Other substitutions, modifications, changes, and omissions may be madein the design, operating conditions and arrangement of the exemplaryembodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and programproducts on any machine-readable media for accomplishing variousoperations. The embodiments of the present disclosure may be implementedusing existing computer processors, or by a special purpose computerprocessor for an appropriate system, incorporated for this or anotherpurpose, or by a hardwired system. Embodiments within the scope of thepresent disclosure include program products comprising machine-readablemedia for carrying or having machine-executable instructions or datastructures stored thereon. Such machine-readable media can be anyavailable media that can be accessed by a general purpose or specialpurpose computer or other machine with a processor. By way of example,such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROMor other optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code in the form of machine-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer or other machine with a processor. Wheninformation is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired or wireless) to a machine, the machine properly views theconnection as a machine-readable medium. Thus, any such connection isproperly termed a machine-readable medium. Combinations of the above arealso included within the scope of machine-readable media.Machine-executable instructions include, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing machines to perform a certain function orgroup of functions.

Although the figures show a specific order of method steps, the order ofthe steps may differ from what is depicted. Also two or more steps maybe performed concurrently or with partial concurrence. Such variationwill depend on the software and hardware systems chosen and on designerchoice. All such variations are within the scope of the disclosure.Likewise, software implementations could be accomplished with standardprogramming techniques with rule based logic and other logic toaccomplish the various connection steps, processing steps, comparisonsteps and decision steps.

What is claimed is:
 1. A method in a Building Management System (BMS),the method comprising: presenting a user interface to a user on a userdevice; presenting, on the user interface, a first object used tocontrol equipment of the BMS; presenting, on the user interface, asecond object used to control equipment of the BMS, the second objectaffected by the first object, the first object presented on a first sideof the second object on the user interface; receiving, via the userinterface, an input from the user, the input comprising a selection ofthe second object; and presenting, on the user interface, a third objectused to control equipment of the BMS responsive to the input from theuser, the third object affected by the second object and presented on asecond side of the second object, the second side opposite the firstside.
 2. The method of claim 1, further comprising presenting, on theuser interface, a fourth object used to control equipment of the BMS,the first object affected by the fourth object, the fourth objectpresented on a second side of the first object opposite the first sideof the second object.
 3. The method of claim 2, wherein the input fromthe user comprises a first input, the method further comprising:receiving, via the user interface, a second input from the user, thesecond input comprising a selection of the fourth object; andpresenting, on the user interface, a fifth object used to controlequipment of the BMS, the fourth object affected by the fifth object,the fifth object presented on a second side of the fourth objectopposite the second side of the first object.
 4. The method of claim 2,further comprising removing, from the user interface, the fourth objectresponsive to the input from the user.
 5. The method of claim 1, furthercomprising presenting, on the user interface, a connector between thefirst object and the second object, wherein the connector identifies alogical relationship between the first object and the second object. 6.The method of claim 5, wherein the connector is interactive and allowsthe user to view a priority associated with the logical relationshipbetween the first object and the second object.
 7. The method of claim5, wherein a value or state associated with the first object is equal toa value or state associated with the second object, the method furthercomprising: presenting, on the user interface, a visual indication thataccentuates the connector.
 8. The method of claim 1, wherein the thirdobject comprises an unbound object that is no longer valid within theBMS, the method further comprising: presenting, on the user interface, avisual indication that alerts the user of the unbound object.
 9. Themethod of claim 1, further comprising presenting, on the user interface,an object address associated with the first object, the object addressselectable by the user to navigate to a settings page associated withthe first object.
 10. A Building Management System (BMS), the systemcomprising: one or more processors; and one or more computer-readablestorage media having instructions stored thereon that, when executed bythe one or more processors, cause the one or more processors toimplement operations comprising: presenting a user interface to a useron a user device; presenting, on the user interface, a first object usedto control equipment of the BMS; presenting, on the user interface, asecond object used to control equipment of the BMS, the first objectaffected by the second object, the first object presented on a firstside of the second object on the user interface; receiving, via the userinterface, an input from the user, the input comprising a selection ofthe second object; and presenting, on the user interface, a third objectused to control equipment of the BMS responsive to the input from theuser, the second object affected by the third object, the third objectpresented on a second side of the second object, the second sideopposite the first side.
 11. The system of claim 10, the operationsfurther comprising presenting, on the user interface, a fourth objectused to control equipment of the BMS, the first object affected by thefourth object, the fourth object presented on a second side of the firstobject opposite the first side of the second object.
 12. The system ofclaim 11, wherein the input from the user comprises a first input, theoperations further comprising: receiving, via the user interface, asecond input from the user, the second input comprising a selection ofthe fourth object; and presenting, on the user interface, a fifth objectused to control equipment of the BMS, the fifth object affected by thefourth object, the fifth object presented on a second side of the fourthobject opposite the second side of the first object.
 13. The system ofclaim 11, the operations further comprising removing, from the userinterface, the fourth object responsive to the input from the user. 14.The system of claim 10, the operations further comprising presenting, onthe user interface, a connector between the first object and the secondobject, wherein the connector identifies a logical relationship betweenthe first object and the second object.
 15. The system of claim 10,wherein the third object comprises an unbound object that is no longervalid within the BMS, the operations further comprising: presenting, onthe user interface, a visual indication that alerts the user of theunbound object.
 16. A device in a Building Management System (BMS), thedevice comprising: one or more circuits configured to implementoperations comprising: presenting a user interface to a user on a userdevice; presenting, on the user interface, a first object used tocontrol equipment of the BMS; presenting, on the user interface, asecond object used to control equipment of the BMS, the second objectaffected by the first object, the first object presented on a first sideof the second object on the user interface; receiving, via the userinterface, an input from the user, the input comprising a selection ofthe second object; and presenting, on the user interface, a third objectused to control equipment of the BMS responsive to the input from theuser, the third object affected by the second object and presented on asecond side of the second object, the second side opposite the firstside.
 17. The device of claim 16, the operations further comprisingpresenting, on the user interface, a fourth object used to controlequipment of the BMS, the first object affected by the fourth object,the fourth object presented on a second side of the first objectopposite the first side of the second object.
 18. The device of claim17, wherein the input from the user comprises a first input, theoperations further comprising: receiving, via the user interface, asecond input from the user, the second input comprising a selection ofthe fourth object; and presenting, on the user interface, a fifth objectused to control equipment of the BMS, the fourth object affected by thefifth object, the fifth object presented on a second side of the fourthobject opposite the second side of the first object.
 19. The device ofclaim 16, the operations further comprising presenting, on the userinterface, a connector between the first object and the second object,wherein the connector identifies a logical relationship between thefirst object and the second object.
 20. The device of claim 16, whereinthe third object comprises an unbound object that is no longer validwithin the BMS, the operations further comprising: presenting, on theuser interface, a visual indication that alerts the user of the unboundobject.